Distributed control systems and methods that selectively activate respective coordinators for respective tasks

ABSTRACT

Respective coordinators are spawned or activated to coordinate activities with regard to respective tasks. Where the respective tasks require cooperative efforts of a plurality of controllers, the respective coordinators ensure cooperative efforts by generating and communicating cooperative commands to the plurality of controllers. The coordinators may act as clearinghouses for system data, selectively requesting and relaying system information to appropriate controllers. For example, a document processing system activates respective coordinators for respective sheets of print media. The respective coordinators orchestrate the transportation of the sheets by sequentially orchestrating the activities of sequentially selected pluralities of transportation actuator controllers. Selected sheet position information from sensors and/or from models maintained by the actuator controllers may be relayed by the coordinators to selected actuator controllers as appropriate to the sheet transportation tasks.

CROSS REFERENCE

The following applications, the disclosures of each being totallyincorporated herein by reference are mentioned: U.S. patent applicationSer. No. 11/102,355, filed Apr. 8, 2005, for Communication in aDistributed System by Markus P. J. Fromherz, et al.; U.S. patentapplication Ser. No. 11/102,899, filed Apr. 8, 2005, for Synchronizationin a Distributed System by Lara S. Crawford, et al.; and U.S. patentapplication Ser. No. 11/102,332, filed Apr. 8, 2005, for On-The-FlyState Synchronization in a Distributed System by Haitham A. Hindi, etal.

BACKGROUND

There is illustrated herein in embodiments, an architecture includingmethods and systems for coordinating activities in a distributed system.For example, a distributed system may include a collection of modules,each with its own function. The collection of modules is interconnectedto carry out a particular function or functions. The interconnection maybe physical and/or logical in nature. Modules may be connected by anetwork or other communications scheme. Communications media may includewire, coaxial cable, fiber optics and/or radio frequency (RF)transmissions. Embodiments will be described with reference to documentprocessing systems. However, embodiments of the architecture may bebeneficially applied in a wide variety of control system environments.

Document processors include, for example, printers, copiers, facsimilemachines, finishers and devices for creating documents, such as wordprocessors and desk top publishers. In some instances, documentprocessors provide the services of two or more of these devices. Forinstance, document processors that provide printing, copying, scanning,and faxing services are available. Printers and copiers can includefinishers that staple, shrink wrap or otherwise bind system output.Finishers may also fold or collate documents.

In order to increase throughput, some printers and copiers are beingdeveloped which include two or more marking engines. For example, U.S.patent application Ser. No. 10/924,113 filed Aug. 23, 2004 by Jonas M.M. deJong, et al. for a Printing System with Inverter Disposed for MediaVelocity Buffering and Registration, which issued on Oct. 17, 2006 asU.S. Pat. No. 7,123,873; U.S. patent application Ser. No. 10/924,106filed Aug. 23, 2004 by Robert M. Lofthus, et al. for a Printing Systemwith Horizontal Highway and Single Pass Duplex, which issued on Apr. 4,2006 as U.S. Pat. No. 7,024,152; U.S. patent application Ser. No.10/924,459 filed Aug. 23, 2004 by Barry P. Mandel, et al. for a ParallelPrinting Architecture Consisting of Containerized Image Marking EngineModules, which issued on Nov. 14, 2006 as U.S. Pat. No. 7,136,616; U.S.patent application Ser. No. 10/860,195 filed Jun. 6, 2004 by Robert M.Lofthus, et al. for a Universal Flexible Plural Printer to PluralFinisher Sheet Integration System, which issued on Jan. 22, 2008 as U.S.Pat. No. 7,320,461; U.S. patent application Ser. No. 10/881,619 filedJun. 30, 2004 by Daniel G. Bobrow for a Flexible Paper Path UsingMultidirectional Path Modules, which issued Jul. 8, 2008 as U.S. Pat.No. 7,396,012; U.S. patent application Ser. No. 10/761,522 filed Jan.21, 2004 by Barry P. Mandel, et al. for a High Print Rate Merging andFinishing System for Parallel Printing, which issued on Dec. 6, 2005 asU.S. Pat. No. 6,973,286; U.S. patent application Ser. No. 10/785,211filed Feb. 24, 2004 by Robert M. Lofthus, et al. for a UniversalFlexible Plural Printer to Plural Finisher Sheet Integration System,which issued on Jun. 5, 2007 as U.S. Pat. No. 7,226,049; and U.S. patentapplication Ser. No. 10/917,768 filed Aug. 13, 2004 by Robert M. Lofthusfor a Parallel Printing Architecture Consisting of Containerized ImageMarking Engines and Media Feeder Modules, which issued on Mar. 13, 2007as U.S. Pat. No. 7,188,929, all of which are incorporated herein byreference, describe aspects of tightly integrated document processingsystems including a plurality of marking engines.

Additionally, some printers and copiers are being developed using ahypermodular structure to increase modularity and flexibility. Thesesystems may possess a number of distributed processors, sensors, andactuators. For example, U.S. patent application Ser. No. 10/357,687filed Feb. 4, 2003 by David K. Biegelsen, et al., for Media PathModules, which issued on Aug. 22, 2006 as U.S. Pat. No. 7,093,831; U.S.patent application Ser. No. 10/357,761 filed Feb. 4, 2003 by Markus P.J. Fromherz, et al., for Frameless Media Path Modules; U.S. patentapplication Ser. No. 10/740,705 filed Dec. 19, 2003 by David K.Biegelsen, et al., for a Flexible Director Paper Path Module, whichissued Sep. 19, 2006 as U.S. Pat. No. 7,108,260; and U.S. patentapplication Ser. No. 10/812,376 filed Mar. 29, 2004 by David G. Duff, etal., for a Rotational Jam Clearance Apparatus, which issued Mar. 6, 2007as U.S. Pat. No. 7,185,888, all of which are incorporated herein byreference, describe aspects of tightly integrated document processingsystems including hypermodules.

Some systems, including some document processing systems, are based on acentralized control architecture wherein a single computational platformcontrols all system actuators and receives all system feedbackinformation. These architectures work well where the systems arerelatively small and are of a fixed or unchanging configuration.However, as system size increases, the computational capabilities of asingle platform can be overwhelmed. Additionally, providing individualinterfaces between the single computational platform and each of thesensors and actuators of the system can be impractical. Furthermore,where it is desirable to assemble or reconfigure a system from varioussubcomponents, the direct interfacing of sensors and actuators to thecentral platform becomes problematic.

These factors have led to the development of systems based on networkcommunications. For example, U.S. Pat. No. 6,615,091 B1 to Birchenough,et al. for a Control System and Method Therefore allegedly disclosed anembodiment of a distributed control system including a main controlcoordinator, three local process station controllers and a designatednumber of process module controllers, each associated with a processmodule. The control system allegedly provides a real time operatingsystem and has a communication bus platform provided via an Ethernet™communication bus and a second bus to connect the controllers in adistributed control network. The Ethernet™ bus connects the main controlcoordinator and each of the local process station controllers and acontinuous motion conveyer controller. Each of the process modulecontrollers are connected via the second bus to designated local processstation controllers.

In the system of Birchenough, the main controller agent interacts witheach of the process station agents, and each of the process stationagents interacts with each of the process module agents that areassigned thereto. During normal manufacturing operation, the maincontroller coordinator agent sends article notice messages to theprocess station agents to notify the process station agents of theoncoming articles of manufacture. A process station normally will notprocess the article of manufacture unless the process station agent thatcontrols a particular process module has received an article noticemessage indicating that it should do so and the continuous feed indexerhas returned a report that it is in proper position. In response, theprocess station agent notifies the designated process module agent toinitiate its programmed process operation. Once the process module hascompleted its intended operation, the process module agent issues a workreport message which is sent to the process station agent. The processstation agent then broadcasts the work report message to other processstations as well as to the main control coordinator.

It appears that in the system of Birchenough, et al., a single entity(e.g., the main coordinator) is aware of and maintains informationregarding each task, object or workpiece being processed by the system.This may limit the scalability of the system. For example, as the sizeof the system increases, the capabilities and/or resources of the maincontrol coordinator (or processor running the main control coordinator)may be overwhelmed.

Accordingly, there has been a desire for a distributed controlarchitecture, including systems and methods, that provides forscalability and reconfigurability in a modular system environment.

BRIEF DESCRIPTION

A method for coordinating controllers in a distributed control systemthat is operative to perform a plurality of simultaneous tasks includesdetermining a respective task of the plurality to be performed andactivating a respective coordinator in association with the respectivetask. The respective coordinator may then identify a plurality ofrespective subtasks to be performed in order to complete the respectivetask, identify a plurality of respective controllers for controlling aplurality of actuators to perform the respective subtasks, generaterespective commands for directing the performance of the respectiveplurality of subtasks and communicate the respective commands to therespective controllers as appropriate to the respective subtasks. Therespective coordinator may also identify at least one respectiveinformation source that is able to provide progress informationregarding the performance of the respective subtasks, collect therespective progress information from the respective at least oneinformation source and communicate the respective progress informationto the respective controllers as appropriate to the respective subtasks.

The method may also include deactivating respective controllers asrespective subtasks are determined to be completed based on thecollected respective progress information, thereby releasing therespective controllers to execute commands communicated from anothercoordinator associated with another task and/or deactivating thecoordinator when the respective task is determined to be completed. Forexample, one or more model may be maintained to estimate progress of therespective subtasks and the coordinator and/or controllers may bedeactivated when the respective subtasks are completed according to theone or more models.

For instance the models can be based on commands the coordinatorgenerates and/or on progress information received from progressinformation sources. The output of command based models and progressinformation models can be compared to determine a task progress errorvalue. The error value can be compared to an error limit. An error task,such as generating an error message or taking corrective or compensatoryaction, can be performed if the error value is beyond the error limit.

Some embodiments include a method for coordinating controllers in adistributed control system that is operative to simultaneously performoperations on a plurality of workpieces. These embodiments can includeactivating a respective coordinator for each respective workpiece,wherein each respective coordinator encompasses knowledge regarding anitinerary of operations to be applied to each respective workpiece. Eachrespective coordinator may then issue respective commands to a series ofactuator controllers for directing a series of actuators to performrespective operations on the respective workpiece according to theitinerary, maintain at least one respective estimate of progress of therespective operations performed on the respective workpiece anddeactivate the respective coordinator when the itinerary of operationsis completed.

A method for processing a sheet in a document processing system caninclude receiving a sheet description specifying a document processingjob to be performed on the sheet and activating a coordinator as a proxyfor the sheet. The coordinator may then identify a plurality ofrespective subtasks to be performed in order to process the sheetaccording to the sheet description, identify, based on the identifiedrespective subtasks, a plurality of respective controllers forcontrolling a plurality of actuators to perform the respective subtasks,generate respective commands for directing the respective plurality ofsubtasks and communicate the respective commands to the respectivecontrollers as appropriate to the respective subtasks. The coordinatormay also identify at least one respective information source that isable to provide progress information regarding the performance of therespective subtasks, collect the respective progress information fromthe respective at least one information source, communicate therespective progress information to the respective controllers asappropriate to the respective subtasks, estimate the respective progressof the respective subtasks and deactivate the respective controllers asthe subtasks are completed. The coordinator may be deactivated when thetask is completed.

A system that is operative to perform embodiments of the methods caninclude a plurality of controllers, at least one supervisor element, anda plurality of information sources. The at least one supervisory elementmay be operative (alone or in combination) to generate respective taskdescriptions describing respective tasks, to activate respectivecoordinators to be responsible for orchestrating completion of therespective tasks and to communicate the respective task descriptions tothe respective coordinators. The plurality of controllers may beoperative to control a plurality of actuators according to respectivesubtask descriptions received from the respective coordinators. Theplurality of information sources may be operative to report statusinformation regarding respective progress of respective tasks to therespective coordinators. For example, the information sources may besensors of the system or models or estimators of the controllers. Therespective coordinators may be operative to receive the respective taskdescriptions, identify, based on the respective task descriptions, aplurality of respective subtasks to be performed in order to completethe task, identify, based on the respective subtasks, a subset of theplurality of respective controllers, for controlling a subset of theplurality of actuators to perform the respective subtasks, identifyrespective subsets of the plurality of information sources that are ableto provide progress information regarding the performance of therespective subtasks, generate respective commands for performing therespective plurality of subtasks, communicate the respective commands tothe respective controllers as appropriate to the respective subtasks,collect the respective progress information from the respective subsetsof information sources and communicate the respective progressinformation to the respective controllers as appropriate to therespective subtasks.

A document processing system embodiment can include one or more markingengines, including, for example a xerographic marking engine.Additionally, the system can include a transportation system that isoperative to transport sheets of print media to and/or from the firstmarking engine. Some embodiments may also include a plurality ofinformation sources that are operative to report status informationregarding respective progress of respective sheet processing tasks tothe respective sheet coordinators. The transportation system can includea plurality of transport actuators, at least one supervisory element, aplurality of respective transport controllers and a module controller.The at least one supervisory element can be operative (alone or incombination) to generate respective sheet processing task descriptionsdescribing respective sheet processing tasks and to activate respectivesheet coordinators to be responsible for orchestrating the respectivesheet processing tasks according to the respective sheet processing taskdescriptions. The plurality of respective transport controllers can beoperative to control respective sets of transport actuators, of theplurality of transport actuators, according to respective sheetprocessing subtask descriptions received from the respective sheetcoordinators. The first marking module controller may be operative tocontrol aspects of processing of a first marking engine according torespective sheet processing subtask descriptions received from therespective sheet coordinators.

For example, the respective sheet coordinators are operative to receivethe respective sheet processing task descriptions, identify, based onthe respective sheet processing task descriptions, a plurality ofrespective sheet processing subtasks to be performed in order tocomplete the respective sheet processing tasks, identify, based on therespective sheet processing subtasks, a subset of the plurality ofrespective transport controllers and the first marking modulecontroller, for controlling a subset of the plurality of transportactuators and the first marking engine to perform the respective sheetprocessing subtasks, identify respective subsets of the plurality ofinformation sources that are able to provide progress informationregarding the performance of the respective sheet processing subtasks,generate respective commands for performing the respective plurality ofsheet processing subtasks, communicate the respective commands to therespective transport controllers and/or first marking engine controlleras appropriate to the respective subtasks, collect the respectiveprogress information from the respective subsets of information sourcesand communicate the respective progress information to the respectivetransportation controllers and/or first marking engine controller asappropriate to the respective sheet processing subtasks.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a system wherein a supervisory element hasactivated, spawned or instantiated a plurality of respectivecoordinators that are responsible for orchestrating respective tasks.

FIG. 2 is a flow chart outlining a method for coordinating controllers.

FIG. 3 is a flow chart outlining a method for coordinating controllersthat includes collection and relaying of information.

FIG. 4 is a block diagram of a document processing system wherein asupervisory element has activated, spawned or instantiated a pluralityof respective coordinators that are responsible for orchestratingrespective document processing tasks.

DETAILED DESCRIPTION

Referring to FIG. 1, a first system 104 embodiment includes a plurality106 of controllers. For example, the plurality 106 of controllersincludes a first, second, third, fourth and fifth controller 108, 110,112, 114, 116. The controllers may, for example, be associated withactuators and sensors. For instance, the first, second and thirdcontrollers 108, 110, 112 are associated with first, second and thirdsets of actuators 118, 120, 122 and first, second and third sets ofsensors 124, 126, 128. The fourth controller 114 is associated with afourth set of actuators 130. The fifth controller 116 is associated witha fourth set of sensors 132. The actuators 118, 120, 122, 130 andsensors 124, 126, 128, 132 manipulate or sense objects in, or aspectsof, respective portions of the system 104. For example, the first set ofactuators 118 and first set of sensors 124 are associated with a firstportion 140 of the system 104. The second set of actuators 120 and thesecond set of sensors 126 are associated with a second portion 142 ofthe system 104. The third set of actuators 122 and the third set ofsensors 128 are associated with a third portion 144 of the system 104.The fourth set of actuators 130 are associated with a fourth portion 146of the system 104 and the fourth set of sensors 132 are associated witha fifth portion 148 of the system 104.

Some or all of the system portions may be tightly coupled. Tightlycoupled systems or system portions are those wherein the performance oractivities of a first system portion has an effect on the performance oractivities of a second portion, even to the point where, if theactivities of the first portion and the second portion are notcoordinated, they may interfere with or disrupt each other. Forinstance, in an automotive system, an engine/transmission subsystem maybe considered to be tightly coupled with a braking subsystem because anuncoordinated application of the braking system may interfere with orprevent the engine/transmission system from propelling a vehicle.

In the embodiment illustrated in FIG. 1, first, second and thirdelements of system dynamics 152, 154, 156 tightly couple the secondsystem portion 142 to the third system portion 144, tightly couple thethird system portion 144 to the fourth system portion 146 and tightlycouple the fourth system portion 146 to the fifth system portion 148.The first system portion 140 is illustrated as having only a loose orminimal interaction with the second system portion 142 and is nottightly coupled thereto.

The first system 104 may also include a supervisor 160 or supervisoryelement. For example, the supervisory element 160 may be a schedulerand/or a planner. The supervisor 160 determines which tasks are to beperformed or which workpieces are to be processed. This element and/orone or more other supervisory elements activate, spawn or instantiate aseparate coordinator for each task or workpiece. For example, a firstcoordinator 170 is activated or spawned in association with a first taskor workpiece, and a second coordinator 180 is activated or spawned inassociation with a second task or workpiece. The coordinators 170, 180are activated and initialized in such a manner as to preventinterference between the coordinators.

For example, if the first task or workpiece and the second task orworkpiece both require the services of the first, second, third, fourthand fifth system portions 140, 142, 144, 146, 148, then, for example,the first coordinator 170 is activated and takes control of the firstsystem portion 140 by communicating with the first controller 108. Theactivation of the second coordinator 180 may be delayed until the firstcoordinator 170 no longer requires the services of the first systemportion 140. Alternatively, the second coordinator 180 is activatedearly and directed to wait or idle until such a time as the firstcoordinator 170 no longer needs the services of a first system resource(e.g., 140).

The first coordinator 170 releases the first controller 108 when thefirst task or workpiece no longer needs the services of the first systemportion 140. The first coordinator 170 may then send commands requestingthe services of another system resource (e.g., the second system portion142) for accomplishing a second subtask. Alternatively, the firstcoordinator 170 may begin requesting services from the second resourcebefore the first resource has completed a first subtask. In either case,the first coordinator 170 sequentially sends commands to the controllers(e.g., 110, 112, 114, 116) requesting services of their respectivesystem portions (e.g., 142, 144, 146, 148). When appropriate, the firstcoordinator 170 sends coordinated commands to a plurality ofcontrollers. For example, if a subtask requires coordinated activitybetween two or more system portions at once, then the coordinatorgenerates coordinated commands to two or more controllers associatedtherewith.

In FIG. 1, the first system 104 embodiment is depicted at a point intime wherein the first task or workpiece requires the services of thefourth system portion 146 and the first coordinator is communicatingwith the fourth controller 114. Proximate to issuing commands to, ortaking control of, the fourth controller 114, the third controller 112may have been deactivated or released from the control of the firstcoordinator 170. For example, commands previously issued to the thirdcontroller 112 might have been associated with an expiration parameter.The expiration parameter may have been, for example, a time limit or aprocessing milestone. When an event occurs that matches or surpasses thevalue of the expiration parameter, the third controller 112 may bedeactivated or released from the control of the first coordinator 170.

Alternatively, the first workpiece or task may require simultaneousservices of both the third system portion 144 and the fourth systemportion 146. In that case, the first coordinator generates andcommunicates coordinated or cooperative commands to the third 112 andfourth 114 controllers.

At an appropriate point, the first coordinator will generate commandsand transmit or communicate them to the fifth controller 116 requestingservices of the fifth system portion 148. If the services of the fifthsystem portion are required contemporaneously with the services offourth 146 and/or third 144 system portions, then the first coordinator170 generates and communicates cooperative commands to the fifth 116,fourth 114 and/or third 112 controllers.

FIG. 1 also illustrates the second coordinator 180 to be incommunication with the second controller 110. For example, the secondcoordinator 180 is requesting services of the second system portion 142.The first controller 108 is being, or has been, released from servingthe second coordinator 180, and the second coordinator 180 is preparingor will prepare to take control, or request the services of, the thirdsystem portion 144 through the third controller 112. Since the second142 and third system portions are tightly coupled 152, the secondcontroller may generate and communicate cooperative commands to thesecond 110 and third 112 controllers, thereby directing them to performcooperative operations or processes on the second task or workpiece. Insome instances, the first coordinator 170 and the second coordinator 180may communicate with each other to facilitate coordination or for otherreasons.

When the first controller 108 is released or deactivated, it becomesavailable to execute commands of yet another coordinator (not shown)which the supervisor 160 may activate, spawn or instantiate tocoordinate and orchestrate a third task or workpiece for processing.

Referring to FIG. 2, a first method 210 for coordinating controllers ina distributed control system can include determining 214 a task to beperformed by the system and activating 218 a coordinator (e.g., 170,180) in association with the task. The coordinator (e.g., 170, 180) maythen identify 222 subtasks to be performed in order to complete thetask, identify 226 controllers for performing the subtasks, generate 230commands to direct the controllers to perform the subtasks andcommunicate 234 the commands to the controllers as appropriate to thesubtasks. The coordinator (e.g., 170, 180) may also monitor 238 theprogress of the subtasks.

Determining 214 may be done by any known task determination method. Forexample, a supervisory element (e.g., 160) may autonomously determinethat a task should be performed. For instance, sensor readings mayindicate that a particular action is required. Alternatively, thesupervisory element may receive instructions from another device orhigher level supervisory device. For example, a system user may entercommands, through a user interface, directing that a task or series oftasks be performed. Alternatively, commands may be received over anetwork or via a wireless link from another system or remote user. Thesupervisory element may translate or transform such commands into a taskdescription or specification and activate 218 a coordinator in accordwith the task specification.

Activating 218 a coordinator in association with the task may includeinitializing a coordinator according to the task specification. Forinstance, a coordinator (e.g., 170, 180) may be embodied in software runby a computational platform such as a microprocessor. One or morecoordinators may be loaded into program memory in an idle state. Thesupervisory element selects an idle coordinator and initializes it inaccord with the task specification, thereby activating the coordinator.Alternatively, activating 218 a coordinator may include spawning orinstantiating a coordinator by creating or loading a new process or byreferencing a program or subprogram. The spawned or instantiated elementmay be initialized or loaded with the task specification or may simplybe selected for spawning or instantiation based on the taskspecification. In a further alternative, the task specification may betransmitted or otherwise communicated to the coordinator at some pointafter the coordinator has been activated 218.

Identifying 222 subtasks to be performed to complete the task andidentifying 226 controllers to perform the subtasks are related to eachother and may occur simultaneously or contemporaneously. For example,identifying subtasks may be dependent on the capabilities of thecontrollers (e.g., 108, 110, 112, 114, 116) and modules or systemportions (e.g., 140, 142, 144, 146, 148) associated with thecontrollers. For instance, if the task specification indicates that ahole is to be drilled in a workpiece, the coordinator (e.g., 170, 180)may have to determine how one system portion (e.g., 140, 142, 144, 146,148) manipulating the piece will have to adjust its control tocompensate for the forces applied by another system portion doing thedrilling.

In some embodiments, it is assumed that all task specifications arevalid. For example, a task specification requiring that a hole be placedin a workpiece would only be communicated to a coordinator if the systemincluded a system portion capable of providing the hole. In otherembodiments, the coordinator (e.g., 170, 180) checks the validity orfeasibility of a task specification and communicates an error orexception message to the requesting entity (e.g., 160) if the specifiedtask is not feasible or valid. In still other embodiments, validity orfeasibility is determined by the controllers (e.g., 108, 110, 112, 114,116) and communicated to the coordinators (e.g., 170, 180), and from thecoordinators to the supervisor (e.g., 160).

Identifying 226 the controllers or system elements to be used tocomplete the task helps identify 222 the subtasks to be performed. Forinstance, subtasks for the hole-stamping example task mentioned abovemight include operating a motor in a transport system so as to move theworkpiece to a hole-stamping module, operating a set of registrationmotors to align the workpiece in the hole-stamping module according to adesired hole location defined in the task specification, installing astamp appropriate for stamping a hole of a size defined in the taskspecification in a chuck, operating actuators so as to stamp the hole inthe workpiece, operating clamps and alignment motors to hold theworkpiece in place in while the hole is being stamped, and operatingmotors in a transport system to move the workpiece out of the stampingmodule. Several of these subtasks would have to be coordinated; forexample, the registration operation must be coordinated with theclamping and stamping operations.

System configuration and/or capabilities information is made availableto the coordinator (e.g., 170, 180). For example, the coordinator may beinitialized, spawned or instantiated with all the required systemconfiguration information. Alternatively, the coordinator may haveaccess to a database or may be able to query or poll all the availablecontrollers in a system to determine their capabilities and, ifappropriate, their relative locations.

Generating 230 commands to direct the performance of the subtasks isalso system or embodiment dependent. In the hole stamping example fromabove, the activated 218 coordinator may generate 230 a command todirect a first controller (e.g., 108) to drive a workpiece ejectionmechanism to eject one workpiece onto a transport mechanism. Anothergenerated command may be for a second controller (e.g., 110), directingthe second controller to drive the transport mechanism at a particularspeed for a particular period of time or until a sensor indicates theworkpiece has arrived at a particular position. Additional commandswould be generated 230 to load and orient the workpiece in the holepunch module and to select, install and drive the punch as well astransport the finished workpiece to an output device.

Communicating 234 the commands to the controllers as appropriate to thesubtasks can include any desired communication mechanism. For example,the activated 218 coordinator (e.g., 170, 180) may communicate with thecontrollers (e.g., 108, 110, 112, 114, 116) over a system network, suchas Ethernet™ or the Controller Area Network (CAN) developed by RobertBosch GmbH. Information regarding the format or protocol used tocommunicate with each controller (e.g., 108, 110, 112, 114, 116) is madeavailable to the activated 218 coordinator, either during initializationor from some system resource such as a memory or database.

As indicated above, the activated 218 coordinator (e.g., 170, 180) mayoptionally monitor the progress of subtasks. For example, the controllermay receive subtask completion messages from the controllers as eachsubtask is completed. Additionally, or alternatively, the activated 218coordinator may establish and maintain a model of each subtask (or thetask as a whole). For instance, where a communicated 234 command directsa controller to drive an actuator to move a workpiece at a given speed,the activated 218 coordinator may maintain a command model thatestimates a position of the workpiece based on the commanded speed. Themodel assumes that the command will be followed. Additionally, oralternatively, the activated 218 coordinator may receive progressinformation from one or more progress information sources. For instance,the activated 218 coordinator (e.g., 170, 180) may receive progressinformation from a controller (e.g., 108, 110, 112, 114, 116) and/orfrom sensors (e.g., 124, 126, 128, 132). The activated 218 coordinatormay maintain a progress model of the subtasks (or task as a whole) basedon this progress information or may use the progress information to finetune or update a command-based model.

Additionally, or alternatively, progress information and/or progressmodel information may be compared to output from the command model. Ifthe progress information or progress model information is very differentfrom progress estimates of the command model (i.e., the difference isbeyond an error threshold), the activated 218 coordinator (e.g., 170,180) may perform some error or exception handling task. For instance, acoordinator may send an error message or warning to a supervisoryelement (e.g., 160). Additionally, or alternatively, the activated 218coordinator may generate 230 and communicate 234 commands to compensatefor or correct the source of the error. For example, if the progressinformation indicates that processing in a first module or systemportion is occurring slower than anticipated or directed by thecommands, updated commands may be sent to a second module or systemportion indicating a delayed start time for processing at that module orsystem portion. Alternatively, commands may be generated 230 andcommunicated 234 to the first module or system portion directing it toprocess a task or workpiece at a faster rate.

The activated 218 coordinator may also act as a clearinghouse forprogress information. Such a service may serve to conserve communicationbandwidth in some systems. For example, referring to FIG. 3, a secondembodiment or method 310 for coordinating controllers in a distributedcontrol system includes determining 214 a task, activating 218 acoordinator, identifying 222 subtasks, identifying 226 controllers,generating 230 commands and communicating 234 the commands to thecontrollers as described above. Additionally, the second method 310includes identifying 314 information sources for providing subtaskprogress information, collecting 318 the subtask progress informationfrom the information sources and communicating 322 the subtask progressinformation to the controllers as appropriate to the subtasks.

Identifying 314 information sources proceeds in a manner similar toidentifying 226 controllers for performing the subtask. Systemconfiguration and capabilities information is received from a memory ordatabase or is provided at activation 218 time. The location andcapabilities of available sensors (e.g., 124, 126, 128, 132) andcontrollers (e.g., 108, 110, 112, 114, 116) are evaluated in light ofthe identified 126 subtasks. If information from a controller or sensorthat is not immediately available to an active controller (e.g., 114,110) would be of benefit to the active controller in completing asubtask, that information source is identified 314. For example,information from the third set of sensors 128 may indicate that aworkpiece is about to become available to the fourth system portion 146.Therefore, the coordinator 170 may request that information from one ormore of the third set of sensors 128 be delivered to the firstcoordinator 170. The first coordinator may then relay 322 the deliveredinformation to the fourth controller 114.

Collecting 318 the subtask progress information may include receivingthe information from information sources after requesting or subscribingto the information from the identified 314 information sources. Again,the information may be received from a network or through othercommunication means.

Communicating 322 the subtask progress information to the controllers asappropriate to the subtasks may include communicating information onlywhen it would be useful to a particular controller. In some embodiments,the progress information is communicated only to those controllers forwhich the information would be useful. This may reduce network traffic.

Identifying 222 subtasks, identifying 226 controllers, generating 230commands, and communicating 234 the commands can be performed one timefor each coordinator activation. Communicated 234 commands can includestart times. Therefore, subtasks that need to occur in the future can berequested in advance. Alternatively, as indicated by the dashed line inFIG. 2, identifying 222 subtasks, identifying 226 controllers,generating 230 commands, communicating 234 the commands and, whereincluded, monitoring 238 (e.g., 314, 318), can occur on a repeated,iterative, or on-going basis as the task or workpiece sequentiallyrequires the services of a new or next system portion (e.g., 140-148).In a further alternative, the identifying 222, 226 and generating 230commands may occur at an initial phase and the communicating 234 of thecommands may occur as the task or workpiece requires the services of thenew or next system portion. Furthermore, generated 230 commands may berevised or replaced as needed.

Referring to FIG. 4, an embodiment of a document processing system 404includes a supervisory element 408, a first marking engine 410, a secondmarking engine 412 and a transportation system 414.

For example, the first and second marking engines 410, 412 may bexerographic marking engines. Alternatively, one or more marking enginesof an embodiment may be of other technologies, such as, but not limitedto, ink jet marking technology.

The transportation system 414 transports print media such as a firstsheet 416 and a second sheet 418 between the first marking engine 410and the second marking engine 412. In the illustrated system 404, thetransportation system includes a plurality of transport modules. Forinstance, the plurality of transport modules includes a first, second,third, fourth, fifth, sixth and seventh transport module 420, 422, 424,426, 428, 430, 432. The system 404 may include additional modules. Forexample, the additional modules may include a media or paper feeder 433,which delivers sheets of print media or paper to one or both of themarking engines 410, 412. Additional modules (not shown) may transportprint media from either or both marking engines 410, 412 to otherdevices, including, but not limited to, additional marking enginesand/or output devices such as paper trays, stackers, collators, staplersand other binders. Furthermore, the plurality of transport modules mayform paths that branch off from the illustrated path (420, 422, 418,424, 426, 430, 432) to transport sheets to other marking engines (notshown) or other devices.

In the illustrated document processing system 404, each transport module420-432 includes transport actuators. For example, the transport modules420-432 include motor driven nips 434 for driving or urging print mediathrough the transport system 414. Additionally, or alternatively, themodules 420-432 may include flippers or gates for redirecting printmedia toward other portions (not shown) of the transportation system414. Furthermore, the modules may include other kinds of transportactuators. For instance, air jets and/or spherical nips may be includedin the transport modules (e.g., 420-432). For the purposes ofillustration, the modules of FIG. 4 are associated with the nips 434depicted to their left. The transport modules 420-432 of the documentprocessor system 404 include sensors. For instance, the sensors may besheet presence or position sensors. As illustrated, each module 420-432includes a left side sensor 436 and a right side sensor 438.

Each transport module 420-432 also includes or is associated with arespective module controller 440, 442, 444, 446, 448, 450, 452. Forexample, the module controllers 440-452 control the actions of thetransport actuators of their respective modules 420-432 and receive andrelay information from their respective sensors 436, 438.

The supervisory element 408 is operative to generate (e.g., 214) sheetprocessing task descriptions or itineraries describing respective sheetprocessing tasks, to activate (e.g., 218) respective sheet coordinators(e.g., a first sheet coordinator 460 and a second sheet coordinator 464)and to communicate the respective sheet processing task descriptions tothe respective sheet coordinators (e.g., 460, 464). For example, thesupervisory element 408 receives a job description 470. The jobdescription 470 may include descriptions of sheets or pages. Thedescriptions may include images, or references to images storedelsewhere and indications as to an order in which the images are toappear on sheets of print media. For example, the job description 470includes page description language describing text and fonts and graphicitems as well as their location on particular pages of a document. Thesupervisory element 408 activates, instantiates or spawns (e.g., 218) asheet coordinator for each sheet or page (a sheet may have two sides andmay, therefore, comprise two pages). The supervisory element 408analyses the job description 470 and may schedule or plan operations tocreate the document described in the job description 470. In so doing,the supervisory element 408 generates respective sheet processing taskdescriptions or itineraries for the transportation and processing ofsheets between system resources.

For instance, regarding the transportation of a sheet between systemresources, an example itinerary or sheet processing task description mayhave the following form:

Itin 1 1 11

feeder1 feed 19.544

me1 print image27 20.201

m1 left2right 23.341

m2 left2right 23.495

m3 left2right 23.625

m4 left2right 23.755

m5 left2right 23.885

m6 left2right 24.015

m7 left2right 24.145

me2 print image28 24.275

finisher1 stack 27.415

The first line is, for example, an itinerary or sheet processing taskdescription identifier. The rest of the itinerary specifies, forexample, that a component named feeder1 (e.g., 433) should feed a sheetat time 19.544, then a component named me1 should execute a print actionon an image named image27 at a later time, then a component named m1should execute an action (move the sheet left to right) at a later time,and so on.

The respective sheet coordinators (e.g., 460, 464) are operative toreceive the respective sheet processing task descriptions or itinerariesand, based on those respective descriptions, identify (e.g., 222) aplurality of respective sheet processing subtasks to be performed inorder to complete the respective sheet processing tasks, identify (e.g.,226) respective controllers for controlling respective process actuatorsto perform the respective sheet processing subtasks, generate (e.g.,230) respective commands for performing the respective sheet processingsubtasks and communicating (e.g., 234) the respective commands to therespective module controllers as appropriate to the respective subtasks.Additionally, the respective sheet coordinators (e.g., 460, 464) mayidentify (e.g., 314) respective information sources that are able toprovide progress information regarding the performance of the respectivesubtasks, collect (e.g., 318) the respective progress information fromthe respective subsets of information sources and communicate (e.g.,322) the respective progress information to the respective modulecontrollers as appropriate to the respective sheet processing subtasks.

For example, the information sources may include the sensors 436, 438.Additionally, or alternatively, the module controllers themselves maymaintain models or estimators of the progress of respective subtasks.Such models are referred to as sheet observer models. In this regard,the module controllers or the estimates or models of the modulecontrollers may be considered information sources.

For instance, in the illustrated document processing embodiment 404,subtasks for a first sheet may have included matching a speed of nips434 of the first module 420 to a speed of a sheet exiting the firstmarking engine 410 and receiving the first sheet 416 therefrom. A secondsubtask might have been for nips 434 of the second module 422 to matchthe speed of the first sheet 416 as it exited the first module 420. Asubtask of the third module 424 may have been to match the speed of thefirst sheet 416 as a leading edge thereof exited the second module 422.Yet another subtask may have been for the nips 434 of the first, secondand third modules 420, 422, 424 to accelerate or to begin to acceleratethe first sheet 416 to a higher transportation system 414 transportspeed.

Additional subtasks associated with the fourth, fifth and sixth modules426, 428, 430 may have included matching associated nip 434 speeds tothe speed of the first sheet 416 as it entered each module 426, 428, 430and/or continuing to accelerate the sheet 416.

The transfer or movement of a sheet from module to module must be donein a coordinated manner. In the document processing embodiment 404, themodules 410, 412, 420-433 are tightly coupled by their relationship to asheet. For example, at any given point in time, a plurality of modulesmay be in contact with the same sheet. If the nips 434 of modulescontacting a sheet are driven at different speeds or with differentrates of acceleration or deceleration, the sheet (e.g., 416, 418) may bedamaged or distorted in a manner that causes a jam in the transportationsystem 414 or system 404 as a whole. The sheet coordinators (e.g., 460,464) ensure cooperative or coordinated actuation of the actuators ormodules (e.g., 410, 412, 420-433). For example, at the instant depictedin FIG. 4, the first sheet 416 is in contact with portions of thefourth, fifth and sixth modules 426, 428, 430. The first sheetcoordinator 460 is shown in communication with the fourth, fifth, sixthand seventh module controllers 446-452. For example, the first sheetcoordinator 460 may be sending commands to the fifth and sixth modulecontrollers 448, 450 that result in the fifth and sixth modules 428, 430driving the first sheet 416 in a cooperative manner. For instance, thefifth and sixth module controllers 448, 450 may be directed to begindecelerating the first sheet 416. Additionally, the first sheetcoordinator 460 may be requesting or receiving sensor information orsheet observer model information from the fourth module controller 446.For instance, the first sheet coordinator 460 may be requesting to benotified when a trailing edge of the first sheet 416 passes the leftsensor 436 of the fourth module. Additionally, the first sheetcoordinator 460 may be asking or receiving sensor information from thesixth module 430. For instance, the first sheet coordinator 460 may berequesting to be notified when a leading edge of the first sheet 416passes or enters a field of view of the right sensor 438 of the sixthmodule.

This sensor information may be relayed by the sheet coordinator to theseventh module controller 452. Additionally, or alternatively, the firstsheet coordinator 460 may update a model, such as a world observer modelof the task or of the subtasks based on the information from theinformation sources or sensors (e.g., 436, 438).

In addition to possibly relaying sensor information, the first sheetcoordinator 460 may be sending commands directing the seventh modulecontroller 452 to prepare the seventh module 432 to receive the firstsheet 416. For instance, the seventh module controller 452 may bedirected to drive nips 434 of the seventh module 432 at a speedcompatible with the speed of the first sheet 416 as the leading edgethereof exits the sixth module 430. Additionally, the fifth, sixth andseventh module controllers 448, 450, 452 may be receiving commandsdirecting that they begin decelerating the first sheet in preparationfor its entry into the second marking engine 412. The first sheetcoordinator 460 may also be transmitting commands to the fourth modulecontroller 446 releasing it from service or subtasks related to thetransportation of the first sheet 416. Alternatively, prior commands mayhave included an expiration event, such as a time limit or sensorreading, the occurrence of which automatically deactivates or releasesthe fourth module controller from services related to the first sheet416.

At a point later in time than the instant depicted in FIG. 4, the firstsheet 416 may enter the second marking engine 412 for processing. Forexample, the second marking engine may be used to print an image on asecond side of the first sheet or may apply color markings that thefirst marking engine 410 did not apply. At that later point in time, thefirst sheet will no longer be in contact with the fourth module 426 andthe trailing edge of the first sheet will be about to exit the fifthmodule 428. The fourth module controller 446 may have already beenreleased (as described above) from subtasks associated with processingthe first sheet 416 and may have begun performing subtasks associatedwith processing the second sheet 418. The fifth module controller 448may be about to be similarly released.

The sixth and seventh transport modules 430, 432 and the second markingengine (or module) 412 are likely all in contact with the first sheet416. Therefore, the first coordinator 460 is generating or has generated(e.g., 230) and will communicate or has communicated (e.g., 234)commands for the sixth and seventh transport modules 430, 432 and thesecond marking engine 412 or a marking engine module controller 474. Thecommands may be cooperative in nature. For example, the transportmodules 430, 432 may be directed to slow the sheet to a speed compatiblewith capabilities of the marking engine 412. Additionally, commands forthe second marking engine controller 474 may direct it to control thesecond marking engine 412 to accept the first sheet at the compatiblespeed and to place specified marks on portions of the first sheet 416.As the first sheet 416 continues into the second marking engine 412, thesixth and seventh module controllers 450,452 will be released fromsubtasks associated with the first sheet 416, or deactivated.Eventually, the first sheet 416 will exit the second marking engine ormodule 412 and be delivered to other modules (e.g., transport modules,finishers, stackers and/or other print engines). The first coordinatorwill continue to send appropriate commands to the subsequent modules,relay progress information and release or deactivate controllers, in thesequential manner described above, until the task described in the taskdescription, or itinerary, received when the first coordinator 460 wasactivated 218 is completed. When the task is completed, the firstcoordinator 460 may be deactivated.

Similar processing occurs with regard to the second 464 and subsequent(not shown) coordinators and second 418 and subsequent (not shown)sheets. For example, as depicted in FIG. 4, the second sheet 418 iswithin the first, second and third modules 420, 422, 424. The secondsheet coordinator 464 is depicted as in communication with the first,second, third and fourth module controllers 440-446. For example, thesecond sheet coordinator 464 may be directing the second and thirdmodule controllers 442, 444 to drive the second sheet 418 at the samespeed and/or with the same acceleration, receiving or requesting sensorinformation from the sensors 436, 438 of the first module 420 and/or thethird module 424, releasing the first module controller 440 from tasksassociated with transporting the second sheet 418, and/or directing thefourth module controller 446 to prepare to receive the second sheet 418by driving nips 434 of the fourth module 426 at a speed appropriate to,or compatible with, a speed of the second sheet 418, as a leading edgethereof exits the third module 424 and enters the fourth module 426. Asthe sheets 416, 418 are transported through the system 404, the sheetcoordinators deactivate or release module controllers no longerprocessing their respective sheets and send commands to downstreamcontrollers preparing them to receive their respective sheets.

Prior to the moment depicted in FIG. 4, the first coordinator generated230 and sent 234 commands to a feeder module controller 478 directing itto control the feeder 433 to deliver the first sheet 416 to the firstmarking engine (or transport modules on a path thereto (not shown)) andmay have generated 230 and sent 234 commands to a first marking modulecontroller 482 instructing it to control the first marking engine 410 toplace particular marks on portions of the first sheet 416 and deliverthe first sheet 416 to the first transport module 420. As mentionedabove, when their respective tasks, as described in their respectivesheet processing task descriptions or itineraries, are completed, therespective sheet coordinators (e.g., 460, 464) are deactivated. Forinstance, they are de-instantiated or placed in an idle mode to awaitre-initialization with information from a new sheet processing taskdescription.

Supervisory element and module controller embodiments may be madesubstantially in software stored in computer storage devices, such asmemory elements, and run by computational platforms, such asmicroprocessors, microcontrollers, and digital signal processors.Alternatively, supervisory elements and module controllers may beembodied in various combinations of hardware and software.

In a prototype, the transport module controllers were each embodied inseparate computational platforms associated with transport modules on aone-to-one basis. Each transport module included a plurality of nips andflippers. Marking engines are known to include their own controllers.The supervisory element 408 was run on one computational platform andactivated or spawned sheet coordinators (e.g., 460, 464) were softwareelements run on another computational platform. However, embodimentswherein the sheet coordinators, or activating data associated with thesheet coordinators, move from module controller to module controller(e.g., 440-452, 474-482) as their respective sheets move from module tomodule (e.g., 433, 410, 420-432, 412), are contemplated.

It will be appreciated that various of the above-disclosed and otherfeatures and functions, or alternatives thereof, may be desirablycombined into many other different systems or applications. Also thatvarious presently unforeseen or unanticipated alternatives,modifications, variations or improvements therein may be subsequentlymade by those skilled in the art which are also intended to beencompassed by the following claims.

1. A method for coordinating controllers in a distributed control systemthat is operative to perform a plurality of simultaneous tasks, themethod comprising: determining, by a supervisory element, respectivetasks of the plurality of simultaneous tasks to be performed;activating, by the supervisory element, respective coordinators inassociation with the respective tasks, the respective coordinatorscomprising software elements run on or by at least one computationalplatform, the respective coordinators then each: identifying a pluralityof respective subtasks to be performed in order to complete therespective tasks; identifying, based on the identified respectivesubtasks, a plurality of respective controllers, for controlling aplurality of actuators to perform the respective subtasks; generatingrespective commands for directing the performance of the respectiveplurality of subtasks; communicating the respective commands to therespective controllers as appropriate to the respective subtasks;collecting respective progress information from at least one respectiveinformation source; and communicating the respective progressinformation to the respective controllers as appropriate to therespective subtasks.
 2. The method of claim 1 further comprising:deactivating, by at least one of the respective coordinators, respectivecontrollers as respective subtasks are determined to be completed basedon the collected respective progress information, thereby releasing therespective controllers to execute commands communicated from anothercoordinator associated with another task.
 3. The method of claim 1further comprising: deactivating at least one respective coordinatorwhen the respective task of the at least one coordinator is determinedto be completed.
 4. The method of claim 1 further comprising:maintaining at least one model of the respective subtasks; anddeactivating at least one of the coordinator and the respectivecontrollers when the respective subtasks are completed according to theat least one model.
 5. The method of claim 1 further comprising:Identifying by at least one of the respective coordinators, at least onerespective information source that is able to provide progressinformation regarding a performance of the respective subtasks.
 6. Themethod of claim 5 wherein identifying at least one respectiveinformation source comprises: at least one of identifying at least onefeedback variable from at least one controller and identifying at leastone sensor.
 7. The method of claim 1 further comprising: maintaining atleast one of a command model of the respective task based on thecommunicated respective commands and a progress model of the respectivetask based on the collected respective progress information.
 8. Themethod of claim 1 further comprising: maintaining a command model of therespective task based on the communicated respective commands;maintaining a progress model of the respective task based on thecollected respective progress information; comparing a first indicatedstatus of the respective task from the progress model to a secondindicated status from the command model, thereby generating a respectivetask progress error value; and comparing the respective task progresserror value to a respective task progress error limit; and performing anerror task if the respective task progress error value is beyond therespective task progress error limit.
 9. The method of claim 8 whereinperforming the respective error task comprises: generating at least oneof a respective error message identifying the respective task anddescribing the respective task progress error and at least one updatedcommand message for correcting or compensating for a respective taskprogress error associated with the respective task progress error value.10. A system comprising: at least one supervisory element, run by acomputational platform, that is operative to generate respective taskdescriptions describing respective tasks, to activate respectivecoordinators to be responsible for orchestrating a completion of therespective tasks and to communicate the respective task descriptions tothe respective coordinators; a plurality of controllers that areoperative to control a plurality of actuators according to respectivesubtask descriptions received from the respective coordinators; and aplurality of information sources that are operative to report statusinformation regarding respective progress of respective tasks to therespective coordinators; wherein the respective coordinators areoperative to receive the respective task descriptions, identify, basedon the respective task descriptions, a plurality of respective subtasksto be performed in order to complete the task, identify, based on therespective subtasks, a subset of the plurality of respectivecontrollers, for controlling a subset of the plurality of actuators toperform the respective subtasks, generate respective commands forperforming the respective plurality of subtasks, communicate therespective commands to the respective controllers as appropriate to therespective subtasks, collect the respective progress information fromthe respective subsets of information sources and communicate therespective progress information to the respective controllers asappropriate to the respective subtasks.
 11. The system of claim 10wherein the respective coordinators are further operative to monitor therespective progress of the respective subtasks.
 12. The system of claim11 wherein the respective coordinators are further operative todeactivate the respective controllers as the subtasks are completed. 13.The system of claim 10 wherein the respective coordinators are furtheroperative to report the respective progress of the respective tasks tothe supervisor and wherein the supervisor is further operative todeactivate the respective coordinators when the respective tasks arecompleted.
 14. The system of claim 10 wherein the at least onesupervisory element is operative to activate the respective coordinatorsby spawning or instantiating the respective coordinators.
 15. The systemof claim 10 wherein the supervisor is operative to activate therespective coordinators by communicating respective task descriptions torespective idle coordinators.
 16. The system of claim 10 wherein theplurality of controllers comprises: at least one of a transport actuatorcontroller, a nip controller, a feeder controller, finisher controllerand a marking engine controller.
 17. The system of claim 10 wherein theplurality of actuators comprises: at least one of a xerographic markingengine actuator, a transport actuator, a nip driver, a feeder actuatorand a finisher actuator.
 18. The system of claim 10 wherein therespective coordinators are operative to identify respective subsets ofthe plurality of information sources that are able to provide progressinformation regarding the performance of the respective subtasks by atleast one of identifying at least one sensor and identifying at leastone feedback variable from at least one controller of the plurality ofcontrollers.
 19. The system of claim 11 wherein the respectivecoordinators are operative to monitor the respective progress of therespective subtasks by at least one of maintaining a command model ofthe task based on the communicated respective commands and maintaining aprogress model of the task based on the respective progress information.20. The system of claim 11 wherein the respective coordinators areoperative to monitor the respective progress of the respective subtasksby maintaining respective models of the respective tasks based on thecommunicated respective commands and maintaining respective progressmodels of the respective tasks based on the respective progressinformation and wherein the respective coordinators are furtheroperative to compare respective first indicated statuses of therespective tasks from the progress model to respective second indicatedstatuses of the respective tasks from the command based model, therebygenerating respective task progress error values, to compare therespective task progress error values to respective task progress errorlimits and to perform respective error tasks if the respective taskprogress error values are beyond the respective error limits.
 21. Amethod for processing a sheet in a document processing system, themethod comprising: receiving at a supervisory element, a sheetdescription specifying a document processing job to be performed on thesheet; activating by the supervisory element, a coordinator as a proxyfor the sheet, the coordinator then: identifying a plurality ofrespective subtasks to be performed in order to process the sheetaccording to the sheet description; identifying, based on the identifiedrespective subtasks, a plurality of respective controllers forcontrolling a plurality of actuators to perform the respective subtasks;generating respective commands for directing the respective plurality ofsubtasks; communicating the respective commands to the respectivecontrollers as appropriate to the respective subtasks; collectingrespective progress information from at least one respective informationsource; communicating the respective progress information to therespective controllers as appropriate to the respective subtasks;estimating the respective progress of the respective subtasks;deactivating the respective controllers as the subtasks are completed;and deactivating by the supervisory element, the coordinator when thetask is completed.
 22. A document processing system comprising: a firstxerographic marking engine; a transportation system that is operative totransport sheets of print media to and/or from the first engine, thetransportation system including a plurality of transport actuators, atleast one supervisory element that is operative to generate respectivesheet processing task descriptions describing respective sheetprocessing tasks and to activate respective sheet coordinators to beresponsible for orchestrating the respective sheet processing tasksaccording to the respective sheet processing task descriptions; aplurality of respective transport controllers that are operative tocontrol respective sets of transport actuators, of the plurality oftransport actuators, according to respective sheet processing subtaskdescriptions received from the respective sheet coordinators; a firstmarking module controller that is operative to control aspects ofprocessing of the first marking engine according to respective sheetprocessing subtask descriptions received from the respective sheetcoordinators, and a plurality of information sources that are operativeto report status information regarding respective progress of respectivesheet processing tasks to the respective sheet coordinators; wherein therespective sheet coordinators are operative to receive the respectivesheet processing task descriptions, identify, based on the respectivesheet processing task descriptions, a plurality of respective sheetprocessing subtasks to be performed in order to complete the respectivesheet processing tasks, identify, based on the respective sheetprocessing subtasks, a subset of the plurality of respective transportcontrollers and the first marking module controller, for controlling asubset of the plurality of transport actuators and the first markingengine to perform the respective sheet processing subtasks, identifyrespective subsets of the plurality of information sources that are ableto provide progress information regarding the performance of therespective sheet processing subtasks, generate respective commands forperforming the respective plurality of sheet processing subtasks,communicate the respective commands to the respective transportcontrollers and/or first marking engine controller as appropriate to therespective subtasks, collect the respective progress information fromthe respective subsets of information sources and communicate therespective progress information to the respective transportationcontrollers and/or first marking engine controller as appropriate to therespective sheet processing subtasks.
 23. The document processing systemof claim 22 wherein the plurality of transport controllers comprises: atleast one of a nip controller, an air jet controller, a flippercontroller and a spherical nip controller.
 24. The document processingsystem of claim 22 further comprising: at least a second marking engine;at least a second marking module controller that is operative to controlaspects of processing of the at least a second marking engine accordingto respective sheet processing subtask descriptions received from therespective sheet coordinators, wherein the transportation system isfurther operative to transport sheets of print media to and/or from theat least a second marking engine; and wherein the respective sheetcoordinators are further operative to identify, based on the respectivesheet processing subtasks, at least a respective one of the at least asecond marking module controller, for controlling at least a respectiveone of the at least a second marking engine to perform the respectivesheet processing subtasks, and communicate the respective commands to atleast a respective one of the at least a second marking modulecontroller as appropriate to the respective subtasks.
 25. A method forcoordinating controllers in a distributed control system that isoperative to simultaneously perform operations on a plurality ofworkpieces, the method comprising: activating, by a supervisory element,a respective coordinator for each respective workpiece, wherein eachrespective coordinator encompasses knowledge regarding an itinerary ofoperations to be applied to the respective workpiece, each respectivecoordinator thereby: issuing respective commands to a series of actuatorcontrollers for directing the series of actuators to perform respectiveoperations on the respective workpiece according to the itinerary;maintaining at least one respective estimate of progress of therespective operations performed on the respective workpiece; anddeactivating the respective coordinator when the itinerary of operationsis completed.